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(54) System for context-dependent name resolution 



(57) A context-dependent, multiply binding name 
resolution system. A name rasolver is provided, con- 
nected to either a requester's system or a receiver's sys- 
tem, or both. Requests to a given service or domain 
name are resolved to the appropriate IP address. The 
intended recipient of the request is resolved based upon 
a combination ot one or more predetermined criteria, in- 
cluding: information about the sender (e.g. geographical 



location, specific requester identity, etc.); information 
about the intended recipient (e.g. load balance at the 
receiver, type of service, etc.); information contained 
within the request itself (e.g. type of service requested); 
or other information (time o1 day, date, random selection 
of recipient, e.g.). The system is implemented in hard- 
ware and/or software, and the resolution criteria can be 
made interdependent or independent. 
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Figure 3 
Service Resolution 
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Description 

This Invention relates to systenns for context-de- 
pendent nanrte resolution. 

In a networl^ (eitlier Intranet or Internet) system, 
when a host wants to communicate with another host or 
locate a service or another host on the network, the ad- 
dress is typically resolved in an absolute manner; that 
is, the naming service of the network resolves a given 
name to a single IP (Internet Protocol) address. For in- 
stance, a domain name sen/ice (DNS) call resolves a 
name to a single iP address or host name on the Inter- 
net 

When there are many connections to a given host 
or service, the resulting congestion degrades the overall 
performance. The sen^ice provider may upgrade the 
sen/ice. e.g. to increase its capacity. In this case, in or- 
der to keep the modification of the sen/ice transparent 
to requesting hosts, a demultiplexer may be used, as 
illustrated by way of example fn Figures 1-2. For in- 
stance, in Figure 1 a call to Sen/ice 3 will be uniquely 
resolved to that service's IP address and transmitted 
there accordingly, because there is only a single binding 
in the DNS name resolver to the host of Service 3. In 
general, in a conventional system such as that illustrat- 
ed in Figures 1 . 2 and 2A, there will be a single binding 
between a name and an IP address. 

Yet another alternative is for a special type of de- 
multiplexer, which may monitor the trafTIc, and from the 
different IP addresses can cxillect statistics such as re- 
sponse time and/or the load on the corresponding IP 
hosts, and use this infonmatbn for load balancing by 
binding a requested name to an IP address for a host 
which is less heavily loaded. 

If Service 3 is upgraded to include Services 3,1 
through 3.Y then the demultiplexer is added (see Figure 
2); the requesting or DNS resolving host resolves the 
request as usual and sends it out over the (Inter- or In- 
tra-)network. but the demultiplexer is interposed be- 
tween the network and the sen/ice(s), to route the in- 
coming requests to one of the sewices. Note that in this 
case, there is still a single binding between the DNS and 
the demultiplexer 

A problem with this approach is that the demulti- 
plexer acis as a limiting factor on throughput, and addi- - 
tionally represents a single source of failure tor all ot the 
services that rt senses. A mechanism is needed whereby 
such a critical point and bottleneck can be avoided, 
while still providing access to the services for remote 
users. ^ 

An alternative approach to decreasing congestion 
is through DNS spoofing, where the name resolver is 
fooled into giving out a different name binding, by keep- 
ing the name resolver updated frequently with a new 

name resolution binding based on some criteria such as 5 
load distribution on target servers. An example of DNS 
spoofing is shown in Figure 2A. in which a requester 2 
issues a request using the name "sun.com". and a DNS 



lookup 4 looks it up. The host (1, 2 or 3) to which the 
names is bound will depend upon criteria employed at 
the destination domain, as determined by DNS spoofing 
service 6. Such criteria may include load on the hosts, 
5 their availability, etc. The DNS spoofing sen/ice 6 polls 
the hosts 1 -3 periodically or at demand, and binds one 
of them at a time to the DNS lookup name resolver for 
the name "sun.com". 

In a spoofing seniles, the criteria used to achieve 
0 the binding are not related to the context of the request- 
er; they rely only upon information at the destination. 
Thus, much information that could be important in mak- 
ing a binding is not utilized. In none of the known sys- 
tems is caller context used. 
> It would accordingly be advantageous to have a 
system which takes Into account the context of the re- 
quester in the process of name resolution. 

Various respective aspects and features of the in- 
vention are defined In the appended claims. 
' A context-dependent name resolution system is 
presented, which implements predetermined criteria for 
static or dynamte binding of a "name" to any one of sev- 
eral "objects" of the same type. Which "object" is select- 
ed for the binding is determined by a "name resolver" 
using context infomnation that is explicitly specified by 
the requestor in a name resolution lookup call to the 
"name resolver". The "name resolver", whteh is imple- 
mented as a server program, stores a fciokup table com- 
prising bindingsof a "name" to several different instanc- 
es of an object along with "policy" information which de- 
fines the criteria for selecting an instance of the object. 
For instance, the name may be an internet URL of the 
form "www.sun.com^ and the resolved to object may be 
an IP address of the type 192.146.85.82. Thus the 
"name resolver" will store the tuple: <wwwsunxom> 
<IP_address_1> <IP_address_2>..., and will store pol- 
icies on which IP address to bind to wwwsun.com when 
a lookup request specifying "www.sun.com" is received 
by it. 

By enabling muittple binding support in the "name 
resolver". several advantages are realized. Firsit. the 
system enables new resources to be added transpar- 
ently to the caller. When a new server is added to dis- 
tribute the toad for one or more hosts corresponding to 
the name "sun.com", for instance, the IP address for the 
new server is simply added to the tuple in the name re- 
solver, along with any desired policy criteria, e.g. to use 
only between 9 a.m. and 5 p.m. 

Secondly, the fundamental limit to scaling whch is 
inherent in today's single binding systems is removed, 
by enabling multiple destination servers providing the 
same QejviceXo be referenced by the same "name* han- 
dle by the caller (for example "sun.com"), and the name 
to be resolved by the name resolver to different physical 
computers servers, depending upon caller context. 
Many instances of the name resolver nnay be mnning 
on different physical computers, and many Instances of 
the sen^ices may be running, and the requester will ac- 
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cess the name resolver closest to him; and the resolved 
object that is closest to the requester or that can best 
serve the request (based upon some selected or prede- 
termined criteria) will be bound to the request, all trans- 
parently to the requester. Another advantage o1 the sys- 5 
tern of the invention is that it allows resources to be eas- 
ily replicated transparently to the user, eliminating any 
single point of failure in the network or at the service end 
point If one valid destination fails, is not responding or 
is overloaded, the name resolver is already capable of 
binding a "name" to multiple destinations, and the una- 
vailable destination can be disabled in the name resolv- 
er's Interna! tables, using administrative means. 

The context that may be used as a basis for the 
binding is variable; it may incfude information about the 
requester (e.g. requester IP address, domain name or 
infened geographical region), about the destination 
(with similar aftematives). about the request itself (e.g. 
type or quality of service requested), or about independ- 
ent information (e.g. lime of day or time zone of the point 
of origin of the request). 

The system may be implemented (eg as part of a 
computer apparatus) using hardware, software, or com- 
binations thereof. 

The invention will now be described by way of ex- 2S 
ample with reference to the accompanying drawings, 
throughout which like parts are referred to by like refer- 
ences, and in which: 

Figures 1 -2 A are diagrams of present network sys- 
tems used for destination addresses for requests. 

Figure 3 is a flow chart illustrating a method accord- 
ing to an embodiment of tine present invention. 

Figures 4 and 5 are diagrams of network systems 
incorporating features of embodiments of the present in- 
vention. 3^ 

Figure 6 in an illustration of the operation of an em- 
bodiment of the invention using geography-based res- 
olution criteria 

Figure 7 is a diagram depicting zones in which do- 
main name service resolvers and service location re- 40 
solvers of the invention may be located. 

A method according to the invention is illustrated in 
Figure 3, and Figures 4-5 shows a suitable systems im- 
piementable on the Internet or Worldwide Web, the In- 
ternet or an intranet,, incorporating features of the name 
resolution system. 

Name resolution can include any kind of name res- 
olution lookup for binding one object to another. This in- 
cludes binding the name of a service to a host computer 
(or its IP address) that provides that service, and binding 
the type of service to the name of a service providing 
that type of service. It also includes resolving a name in 
one donr^ain to another name in the same domain, and 
to another name in a different domain. For the purposes 
of this invention, the terms ■service" and "host" can be 
considered synonymous, as can "service location" and 
"host location'. 

The system includes three fundamental features 



that can b© implemented singly or in any combination 
with one another: multiple binding of destination ad- 
dresses to names; caller context name resolution in con- 
nection with such multiple binding; and name resolution 
policy considerations, i.e. independent criteria upon 
which such resolution is based. 

Name Resolution : An Exampfe 

An example of name resolution occurs, for instance, 
when a user wishes to view video, e.g. a movie, on his 
or her computer. An application running on the computer 
is used to make a procedure call to the name resolver 
to detenmine which server can serve a movie, e.g. 

servbe_handle = name_serviceJookup("movie") 
where the string "movie" is passed to a server, which 
then returns the name of the service providing that mov- 
ie (or it may return a linked list of sen/ices providing mov- 
ie services, from which the user may be prompted to 
select one). 

The server may, by way of example, return a single 
service name (e.g. "quicktime") in the variable called 
''service_handle'. Next, the application must determine 
which server host can provide this service to this client; 
to do this, it makes another name resolution call: 

host_handl6 = name_hostnamejookup 
(service_hand|e) 

and passes it the variable •'service_handle" returned by 
the previous call. This call returns it the name of a server 
which is listed as offering this service. 

The network location of this server must now be de- 
temnined, so that the user's computer or workstation can 
connect to it to get the movie service, and so it makes 
the call: 

host_IP_address = nome„hostaddressjookup 
(host_handle) 

and finally obtains an IP address of an appropriate host 
that can provide the movie service to the user. 

F u rthe r calls to this quicktime server may determine 
a list of nr>ovies that are available. Alternatively, a design 
may be had in which the caller simply specifies the name 
of the movie he wants to see, and the name lookup re- 
turns to the caller the IP address of a host that is cur- 
rently able to serve the requested movie to the caller. 

All of or some of the above steps may be combined 
in nrxDre integrated calls to the name resolver. 

In the present invention, in addit'ion to the above, 
an additional parameter is passed to the 
name_hostaddress_lookupO function above (or to all 
the lunctrans above); this parameter may be called the 
caller_context. This caller_context is used by the name 
resolver to help it decide which IP address to use. Thus, 
the calls would look like: 

host_IP_addreBe - name_hostaddress_lookup 
(host_handle: caller^context). Caller.context is a cook- 
ie (or structure) that may include infomnation such as the 
caller's IP address, its point of origin, the quality of the 
requested service, or any other context that might be 
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relevant These contexts must be well specified and 
their format(s) standardized, so that many different 
name resolvers can interoperate properly. The particu- 
lar caller_contexl formats and contents selected are not 
themselves crucial, 5 

The present embodiment uses requester context- 
dependent intelligence to delenmrne which of several 
destination hosts should be utilized, or in other words, 
which of several IP addresses should be used to resolve 
a given "name" request. The context-dependent rntelli- io 
gence. implemented as hardware or software or a com- 
bination of both, allows the "name" resolution to be 
based upon some context information from the reques- 
tor, and/or upon the 'nam©^ being resolved in a context- 
free manner, but optionally dependent upon criteria is 
such as load balancing on the destination. 

As shown in Figure 4, a requesters 100-120, of 
which there nnay be an arbitrary number, each comprise 
computers or workstations on a local network, sensed 
by a server 150. The requesters will typically be conven- 
tronal workstations, personal computers, or any net- 
workable computing device, with local processors (130, 
etc.), mennory (1 40, etc.), mass storage (not shown) and 
network connections. The sen/er 150 also includes a 
conventional processor 160, memory 170, mass stor- 2S 
age and necessary connections and control hardware 
and software. 

A name resolver IBOfonns part of the sen/er 150, 
or may be a separate unit. It may be implemented en- 
tirely in software, Le. as program modules stored in 30 
mass storage and/or the memory 170, or It may be a 
stand-alone device, with its own logic or processor and 
memory, as desired. 

The sen/er 150 is connected to a broader network 
170, such as the Internet, an IntranetorWAN (wide-area 3S 
network), or the Worldwide Web, via a network connec- 
tion (e.g. a T-line) 260. On this network 170 is optionally 
another name resolver 200. which may be implemented 
in the samefashion or differently from the name resolver 
180. Name resolvers 180 and200maybath be used, or 4o 
either may be used by itself. (See discussion of Figure 
7, below.) 

DesttnatiOT hosts 21 0-230 may also be convention- 
al computers or workstations with processors (such as 
240), mennory (such as 250), mass storage (not shown), 45 
network connections, etc.. as needed to implement con- 
ventional network functions in addition to the features of 
the present invention. 

Referring to the flow chart of Rgure 3, when a re- 
quester (such as 1 00-1 20) sends a name resolution re- so 
quest to a name resolver 1 80. instead erf the single bind- 
ing of conventional systems, the name resolver 1B0 in- 
cludes multiple binding tables anchor functions (imple- 
mented by appropriate togic or program modules) to re- 
solvethe requestto an appropriate IP address for a des- ss 
tination host (such as 210-230 in Figure 4). 

An example of such a multiple binding would be the 
binding of multiple, geographically disparate destina- 



tions to a single domain name. If. for instance, a user in 
Germany wishes to access www.sun.com (the WWW 
sen/erforSun Mterosystems. Inc.)* he or she can simply 
use the Uniform Resource Locator (URL) "httpV/www. 
sun.com"). Thus, the user sends the request from re- 
quester 310 (see Figure 6), and the name resolver 320 
detenmines that the requester is in Germany. (See step 
20 in Figure 3). The selected destination may either be 
in the United States or elsewhere rn Europe, since Sun 
Microsystems in this example has two "sun.com'^ loca- 
tions. Since there Is a valid European local destir>ation 
330, the name resolver 320 resolves the d©stinatk>n ad- 
dress to sun.com (Europe), as indicated at box 30 of 
Figure 3. This resolved destination is then selected for 
the request packet(s) (box 40 of Figure 3), and the re- 
quest is foHA^arded to sun.com (Europe) (box 50 of Fig- 
ure 3). 

Following are lists of context-dependent resolution 
criteria applicable to the invention and usable at box 30 
or Figure 3, where resolution may be based upon re- 
quester information, destination Information, request 
contents, or other information: 

A. Resolution Based Upon Requester fnformatian 

Examples of manners in which the resolution de- 
pendent upon requester information may be carried out 
include: 

1. resolution based upon the domain name of the 
sender 

2. resolution based upon the Inferred (looked-up) 
actual geographic region of the sender; 

3. resolution based upon other geography-related 
information of the sender: 

4. either directly ascertainable from the request 
(city/country info, e.g.); and/or 

5. indirectly ascertainable (area code, address 
etc.); 

6. resolution based upon quality of service desired 
by the requester; and 

7. resolution based upon requester's time of day or 
time zone. 

B. Resolution Based Upon Destination Information 

Examples of manners in whrch the resolution de- 
pendent upon a specified or intended destination or re- 
ceiver infonmation may be carried out include: 

1 . resolution based upon the load at the receiver; 

2. resolution based upon the inferred (looked-up) 
actual geographfc regkin of the receiven 

3. resolution based upon other geography-related 
information of the receiver: 
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4. either directly ascertainable from the request 
(cjly/country info, e.g.); and/or 

5. indirectly ascertainable (area code, address, 
etc.). 

Criterion B. 1 can be resolved either based upon in- 
forniation as perceived at the sender end or based upon 
information as it exists at the receiver end, and resolved 
at the sender end. For example, the sender might fre- 
quently send requests to a particular server, service, ge- 
ographical region or organization. In this case, it may be 
advantageous to regularly poll one or more often-used 
destinations to determine their level(s) of activity. Alter- 
natively, such polling could automatically be carried out 
for any destinations for which the sender determines 
that its number of requests exceeds a certain threshold, 
or for a lop predetermined percentage of requests sent 
by the requester (e.g. all destinations for which the 
number of requests exceeds M%, or the top N2 desti- 
nations to which the sender makes requests, where N1 
and N2 are appropriate predetermined numbers). Polf- 
ing can be implemented as program modules integral to 
the name resolver(s), either entirely in one or in more 
than one location (e.g. partially in a local name resolver 
and partially in the destination server). 

Alternatively or in addition, criterion B.1 may be 
based upon information at the receive end at the time 
of sending the request, and resolved at the receiver 

C. Resolution Based Upon Request Contents 

1, type of service requested; 

2. specific infornnation (or type of infomnation) re- 
quested; 

3, any other implicit information inferred from the re- 
quest; and/or 

4. any other explicit information obtained from the 
request. 

D. Resolution Dependent Upon Other Factors 

1. randomly generated selection of destination 
based upon qualified list; and/or 

2. other independently developed information. 

These resolution criteria can be used singly or in 
any desired combination with one another, as specified 
by the requester or the administrator of the destination 
(e.g. server owner or service provider). For instance, in 
the example of Figure 6the resolution of the destination 
address to sun.com (Europe) could be modified if the 
load of sun.com (Europe) is larger by some predeter- 
mined threshold amount than the load at sun.com (USA) 
~ in which case the sun.com (USA) resolution could 
override the default sun.com (Europe) resolution for re- 
questers in Europe, either at all times or only during 
peak European hours, which correspond to off-peak 
hours in the United States. 



An extension of this system is in the resolution of 
services provided at the receiver network of a request 
For instance, a given organization may have nriany da- 
tabase servers, and request for access to given '\nfor- 
s mation may in conventional systems be routed to the 
same server, because of the single binding nature of 
destination resolution. With multiple address resolution 
binding, multiple database servers (or other destination 
hosts) such as 210, 270, 280. etc. (see Figure 5) may 
be made available under a single name, in which case 
a local service resolution server, such as server 300 in 
Figure 5, is provided. The server 300 includes tables, 
program modules or the like as desired to resolve a re- 
quest to any one of several to many IP addresses. The 
selection of a given server to receive a request can de- 
pend upon, for example, load at each of the servers. 

In general, the resolution systems or subsystems 
will be in one of three "zones" (see Figure 7): the send- 
er's zone 1 (up to, e.g., the sender's firewall or Internet 
server); the name resoh/er system's zone 2 (which may 
be at a server on the Intemet, or any place outside zone 
1 which is not in the receiver's system; and the receiver's 
zone 3. Service location name resolvers may be in any 
of zones 1-3; typically, destination lookup name resolv- 
ers, which may comprise multiple-binding domain name 
services (DNS'a), will be in either zone 1 or zone 2. It 
will be understood that zones, for the purpose of this 
application, are administrative boundaries, and need 
not correlate to actual network boundaries. 

The present embodiment can interact with existing 
systems in a number of ways. For instance, in secure 
systems where the source address is stripped from the 
request by a firewall (and only, e.g.. the domain name 
remains), then the entire source addfess would not be 
used to resolve the destination; the name resolver is 
provided with the program instructions or circuitry to im- 
plement this. Note also that the DNS name resolution 
may be a distinct operation from service location, and 
thus the destination can be selected due to a combina- 
tion of considerations including source address, re- 
quested destination address, and request contents, in- 
cluding the type of request nnade or service requested. 

The multiple binding feature of the invention allows 
a single name, Internet address (e.g. URL address such 
as htip://www.sun.com) or the like to represent as many 
actual servers (or services) as desired. This has a dis- 
tinct advantage of allowing modifications, upgrades or 
replications to be made to the destination 6erver(s) with- 
out modification of the destination address or service 
name as used by the requester. Such modifications may 
include adding servers or services, or establishing a mir- 
ror site at a location geographically near a large source 
of requests, etc. 

There nnay be security and consistency implications 
of multiple bindings, with concomitant solutions. If a des- 
tination address can be multiply bound, a name resolver 
may be configured to bind to an incorrect address, either 
deliberately or otherwise. While this may also be a prob- 
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lem with existing single binding, multiple binding may 
complicate detection of the problem. Thus, the system 
of the invention may be combined with programs and 
tables for verification that a given binding is valid. Very 
secure systems may wish to iimft their multiple binding 
to a predetermined, fixed number of resolution possibil- 
itles» or even maintain the current system of single bind- 
ing as far as internet or Web transmission is concerned, 
and Implement multiple binding only behind a firewall. 
Alternatively or rn addition, encryption and digital signa- 
tures may be used to ensure validity of bindings, and of 
modifications or additions to the bindings. 

Variations may be had by designating a given name 
resolution as a default resolution, and utilizing alterna- 
tive resolutions only upon the request meeting prede- 
ternnined criteria (such as load imbalance, geographical 
distance, specif ic sources of Ihe request, etc.). 

Additional bindings (l.e. additional addresses to 
which a request may resolve) may be added without the 
requester being aware of it, and indeed subslitulions 
may be made at any time, again transparently to the re- 
quester. 

F. Service Selection Based Upon Caller Context 

The system of the invention may be applied more 
generally to the use of caller contesctfor name resolution. 
Context about the requesting user (e.g. in a variable 
called ''call6r_context*') can be passed to appropriate 
functions, such as: 

service_handle = name_sen/ice_lookup("movie", 
caller_context) 

host_handle = name_hostname_lookup 
(service_handle, caller_context) 
Here, the function service^handie executes a service 
name lookup based upon the Input "movie", as well as 
the infomiation in the variable calIer_context, outputting 
the value service_handle. Giveri this output as input, 
along with (again) caller_context, the function 
host.handle then retums an appropriate host name. 

An example of a possible such situation could result 
when a user desires an encryption service, and several 
encryption policies are available. The service.handie 
function can be configured to return different encryption 
algorithm services based upon the specified destination 
(which is specified \n caller_contexl), or there may be 
an effective override in the caller_context by which the 
user can select a higher level of security. 

In general, as noted above, the invention may be 
implemented at the sender's system or at the destina- 
tion system, or indeed at points in between (e.g. at proxy 
servers). Note that single points of failure and bottle- 
necks are removed using the present system, and a truly 
distributed, multiply binding name resolution system is 
achieved. 

Particular and preferred aspects of the inventk>n are 
set out in the accompanying independent and depend- 
ent claims. Features of the dependent claims may be 



combined with those of the independent claims as ap- 
propriate and in combinations other than those explicitly 
set out in the claims. 



Claims 

1 . A systemforname resolution of at least one request 
directed to a destination name of a receiver and is- 
'0 sued from a requester system, including: 

a name resolver connected to the requester 
service and including 

predetermined information correlating a plural- 
'5 ity of destination addresses with said destina- 

tion name; 

a criteria selection subsystem configured to 
provide a selection of at least one said destina- 
tion address based upon at least one predeter- 
2^ mined criterion; and 

a destination address binder configured to bind 
said destination name with said selected desti- 
nation address. 

25 z The system of claim 1, wherein said at least one 
predetermined criterion includes a criterion based 
upon information explicitly contained within said re- 
quest. 

30 3. The system of claim 2, wherein said information in- 
cludes an address of said requester 

4, The system of claim 2. wherein said informatbn is 
based upon at least a portion of contents of said 
request 

5. The system of claim 4, wherein said portion of sakj 
contents includes at least one at 

atype of sen^lce requested by said request; and 
a quality of service requested by said request. 

6. The system of claim 1 , wherein said at least one 
predetermined criterion includes a criterion based 
upon information not explicrlly contained within said 
request 

7, The system of claim 6, wherein said information 
pertains to a geographical region of said requester. 

8- The system of claim 6, wherein said information 
pertains to a geographical region of said receiver. 

9. The system of claim 6. wherein said infomiation in- 
cludes load intormation relating to said receiver. 

10. The system of claim 6, wherein said information in- 
cludes at least one of time and date informatbn. 
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11. The system o1 claim 1 . wherein said binding is to a 
port at said destination address. 

12. The system ot claim 1, wherein said binding is 
based at least in part upon a random selection ot 
one said destination address. 

1 3. A method tor context-dependent binding of a desti- 
nation name to a destination address in a name re- 
solver having a predetermined set of binding criteria 
and predetemnined correlations of destination 
names with destination addresses, wherein at least 
one said correlation is a multiple correlation corre- 
lating a plurality of said destination addresses with 
a single destination name, including the steps of: 

(1) receiving said request at said name resolv- 
er; and 

(2) based upon said multiple correlation, re- 
trieving at least one said destination address 
from said plurality of destination addresses. 

14. The method of claim 13, further including after step 
2, the step of: 

(3) binding said retrieved destination address 
to said destination name. 



a random factor generated by said name re- 
solver. 

21 . A system for name resolution of at least one request 
B directed to a destination name of a receiver and is- 
sued from a requester systenn, the request infornna- 
tion relating to caller context, the system including: 
a name resolver connected to the requester 
service and including 

70 

predetermined information correlating a plural- 
ity of service names with said caller context; 
a service selection subsystem configured to 
provide a selection of at least one said service 
75 name based upon said caller context; and 

a host name selection subsystem configured to 
return a host name based corresponding to 
said selected sen/ice name. 

20 22. The system of claim 1, wherein said at least one 
predetermined criterion includes: 

a first criterion based upon information explic- 
itly contained within said request; and 
2B a second criterion based upon information not 

explicitly contained within said request 



15. The method of claim 1 4, further including after step 
3, the step of: 

(4) transmitting said request with said desti- 30 
nation address. 

16. The method of claim 13, wherein said multiple cor- 
relation is based upon informatiori explicitly con- 
tained within said request. 



23. The system ot claim 22, wherein said second crite- 
rion corresponds to a predetermined policy used by 
said nanne resolver. 

24. The system of claim 23, wherein said first criterion 
corresponds to information relating specifically to 
said requester system. 



17. The system of claim 13, wherein said multiple cor- 
relation is based upon at least a portion of contents 
of said request. 

40 

18. The system of claim 13, wherein said multiple cor- 
relation is based upon at least one of: 

an address of said requester; and 

a type of service requested by said request; and <b 

a quality ot service requested by said request. 

1 9. The system of claim 1 , wherein said multiple corre- 
lation is based upon information not explicitly con- 
tained within said request. 

20. The system of claim 1 9. wherein said multiple cor- 
relation is based upon at least one of: 



a geographical region ot said receiver; 
load information relating to said receiver, 
time infomnation; 
date infomnation; and 
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